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ABSTRACT 

XRTD is a graphical user interface (GUI) based 
tool for monitoring real time radiometric 
spacecraft data. The tool is designed to allow 
the navigation analyst to both view and analyze 
the characteristics of Doppler and ranging data. 
This capability is critical, if ground personnel 
wish to verify the correct performance of 
ongoing maneuvers. The raw tracking data is 
transferred from Deep Space Network (DSN) 
computers to a local workstation, where the 
predicted value for the observable is subtracted 
from the actual observed value to create a 
residual. The tool then allows the navigation 
analyst to rescale and replot the data using 
simple GUI techniques. The navigator may then 
perform a number of data analysis and 
modeling techniques on the resulting residuals 
to allow for the real time characterization of 
spacecraft events. These techniques include the 
modeling of maneuvers, the compression and 
differencing of data, and Fast Fourier transforms 
of the data. This tool has shortened the amount 
of time required for initial characterization of 
spacecraft maneuvers from several hours to a 
few minutes. 

Key Words: Aerospace, space, navigation, 
operations, GUI, XWindows 

1. INTRODUCTION 

The display and analysis of radiometric tracking 
data is, and has always been, fundamental to the 
navigation of interplanetary missions. 
Traditionally, these two functions have been 
somewhat bifurcated. Display usually meant 
generation of plots of data residuals (the 
difference between the value of an observation 
and the expected value of that observation from 
the numerical models) to look for general trends 
in data priori to its analysis or to assure that no 


gross abnormalities remained in the data after 
analysis. Analysis traditionally consisted of 
number-crunching on large main-frame 
computers and the output was ordinarily 
tabular text. 

The workstation revolution, providing powerful 
compact computers equipped with high 
resolution graphics displays and high quality 
output devices, as well as the possibility of 
mouse driven operation of software, resulted in 
anew type of navigation tool, the graphical- 
analysis program. The computation speed of the 
workstations coupled with the growing 
prevalence of high speed data networks (such as 
those based on TCP/IP) further allows the 
graphical analysis tools to be connected to the 
real-time flow of data. This creates capabilities 
not previously possible and enhances previously 
existing ones to previously unthought-of levels. 

1.1 Background 

The basic radiometric observations received 
from spacecraft are Doppler and range data. 
Doppler data is simply tike difference between 
the frequency of the radio signal received by the 
tracking station as compared to the frequency of 
the signal that was originally broadcast. This 
signal may have been broadcast by the receiving 
station and relayed by the spacecraft (2 way 
Doppler), transmitted by a second ground 
station and relayed by the spacecraft (3 way 
Doppler), or originated by the transmitter on the 
spacecraft itself (1 way Doppler). Range data 
can simply be thought of as the time delay 
between when a specified signal is broadcast 
from the originating ground station to when it is 
received back on the Earth. Like Doppler data, 
range data can be either 2 way or 3 way 
depending on if the transmitting station is the 
receiving station. (1 way range data is not used 
in interplanetary navigation.) Conversion of the 
received radiometric signal to data residuals 
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involves both the removal from the received 
signal of calibration values which depend on the 
ground station configuration and conversion of 
the predicted position and velocity of the 
spacecraft to an expected value of either Doppler 
shift or signal delay. In the case of Doppler data 
the received frequency of the data is subtracted 
from the transmitted frequency at a time which 
is twice the light time to the spacecraft before the 
receipt time. The primary problems with range 
data are applying the calibration for the delay 
induced by the receiving and transmitting 
stations and calculation of the ambiguity of the 
range delay. The ambiguity is such that for an 
observed signal delay, d, the actual delay is 

nk + d [Eq. A] 

where k is a constant which depends on the 
ground station configuration and n, the range 
ambiguity, is a positive integer. Fortunately, k is 
generally large enough and a priori knowledge 
of the Earth relative range good enough that 
calculation of is possible. 

The primary purpose of a real-time graphical 
analysis tool is to perform real-time data 
validation and real-time spacecraft analysis. The 
first allows navigators to assess the effect of 
spacecraft and ground station configuration 
changes on data quality or availability. For 
example, this allows the determination of 
transmitter power to allow successful 
acquisition of data without requiring many 
passes of data to slowly determine the minimum 
value. The second purpose allows analysts to 
examine spacecraft activities as soon as the 
effects are visible at the Earth. These activities 
can include maneuvers or anything which 
changes the physical state of the spacecraft. 

1.2 Precursor methods 

In the past other methods have been used for 
near real-time data validation and analysis of 
spacecraft activities. The most common of these 
are referred to as real-time pseudo-residual 
displays and near real-time residual plots. 

The first of these is a display capability provided 
by the DSN. The DSN calculates the expected 
received frequency received at a ground station 
based on a predicted spacecraft state file and 
based on predicted values of the ground station 


configuration. When the actual signal is 
received, this predicted received frequency is 
differenced from the actual received frequency 
to calculate a pseudo-residual. These pseudo- 
residuals are then sent to low resolution displays 
which are in the possession of the flight team 
analysts. The drawbacks of the system are that a 
long lead time is required for the generation of 
these predicted values. If the ground station 
configuration at the receiver or transmitter is 
changed between the time the predicted values 
are generated and the actual observation, then 
the pseudo-residuals may be grossly wrong. 
Additionally, the fairly low resolution of the 
displays makes the determination of precise 
values difficult. No way to import the 
information from the displays into any analysis 
package exists. Finally, pseudo residual 
displays are not available for range data. 

The second method for performing data 
validation tasks and for analyzing spacecraft 
activities was use of a near real-time residual 
plot. In general, this system was only used for 
analysis of maneuvers. This system involved 
using a high resolution plot of data generated by 
the analysts who first receive the data. The 
normal function of this group is to examine the 
data for gross calibration errors and if possible 
repair them and to remove obviously bad data 
points. However, this group can produce higher 
resolution plots of true residuals. Using these 
plots the navigation analysts then attempted to, 
by eye, place curves (usually linear) through the 
data and from the curves calculate the value of a 
maneuver. This system had the obvious 
drawback of being only as precise as the ability 
of the individual analyst to place the line 
through the data. For a typical spacecraft 
maneuver this could only be on the order of 5%. 
Additionally, the generation of these high 
resolution plots generally took in excess of one 
hour. 

The desire to combine the true residuals and the 
high resolution capability of the near real-time 
residual plots and the real-time nature of the 
pseudo-residuals with a tool which removed the 
human element in placing curves through the 
data led directly to the design of the XRTD 
system. 
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2. SYSTEM DEVELOPMENT 

Several basic capabilities are required of any 
real-time navigation graphical analysis tool. 
Access to real-time data must be had, calculation 
of residuals from the basic tracking parameters 
must be achieved, and then the display an 
analysis of the residuals must be accomplished. 

The difficulty of combining all three of these 
functions into a single program as well as a 
desire to as much as possible utilize already 
existing software tools resulted in a decision to 
split the three function into four pieces of 
software. The first two transfer real-time data to 
the analyst’s workstation, the third generates the 
residuals, and fourth is the actual graphical 
analysis software. The advantage of this system 
is that all three functions can be developed and 
tested separately. Additionally, much prior 
work has been done in the generation of 
residuals that could be drawn upon. 

2.1 Data flow structure development 

For simplicity, the decision was made to not 
attempt to develop interfaces directly with the 
data flowing from the DSN stations, but rather, 
to tap into the flow of data after it had already 
been collected at one point. The advantage of 
this is obvious, however the primary 
disadvantage is that the computer 
where all the data is brought together did not at 
the time of the software development have 
direct access to any analysts machine. However, 
a secure interface machine did exist and the 
decision was made to utilize it to provide the 
data flow. Two processes facilitate the data 
flow. The first resides on the intermediary 
micro VAX. It tests for the existence of new data 
on the primary data collection machine and if it 
exists, then transfers the data from the data 
collection machine to the navigation 
workstation. The second simply receives the 
data on the navigation workstations and 
updates the data file on this machine. As this 
file is updated, the third piece of software 
generates the residuals and corresponding 
timetags. These are then output as an updated 
ASCII text file which can be read by the 
graphical analysis software. A block diagram 
of this data flow can be seen in Figure 1. The 
two tools which transfer the data are named 


sprnet and sprd. The residual generation tool is 
called rtd and the graphical analysis tool is Xrtd 



Figure 1: Block Diagram of Data Flow 


2.2 Analysis tool development 

One of the major advantages of the system 
described in the previous section is that the 
development of the graphical display and 
analysis tool is decoupled from the data 
acquisition and calculation portion of the 
problem. Analysis of commercially available 
graphical analysis tools indicated that none met 
the unique needs of the real-time display 
problem. Consequently, the decision was made 
to develop an independent tool to perform this 
analysis. The tool was designed using the X- 
Window System (commonly called Xwindows) 
developed by the Massachusetts Institute of 
Technology (Ref 1.). This windowing system 
provides the advantages of being portable and 
non-hardware vendor specific. Additionally, it 
provides basic capabilities from which any 
graphical user interface (GUI) can be built. The 
mode in which Xrtd was developed and 
designed to be used in integrates an Xwindows 
based system with the OSF/Motif GUI 
developed by the Open Software Foundation 
(Ref. 2). These two choices maximize the 
software portability. 

The design philosophy was to provide a series of 
basic capabilities for displaying data such as 
rescaling the data plots and changing the time 
span of the plots which would not necessarily 
require use of keyboard inputs. Consequently, 
the plot span can be controlled via slider bars 
and the plot can be rescaled simply by selecting 
a rectangular portion of a plot with the mouse. 
The plot will be rescaled to display that portion 
on the whole plot. 
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Additionally, analysis of the data is undertaken 
by creating new plots which are described as 
"children" of the plot from which they 
originated. New "children” are spawned simply 
by accessing a command on a pull down menu. 
The "child" plots may in turn be treated as a 
"parent" and spawn more "children". 
Consequently, complicated adjustments and 
analysis may be performed on data by coupling 
simple processes together in series. A single 
"parent" plot can have multiple "children", thus 
allowing the on screen comparison of differing 
data analysis strategies. A graphical display of 
all plots is maintained to prevent the user from 
becoming confused and the user can access any 
plot by selecting its icon from the plot-tree. A 
number of "child” plots as well as the plot 
summary chart and the pull down menu which 
generates "child" plots can be seen in Figure 2. 



Figure 2: Xrtd mndows xvith plot tree display 


3. SYSTEM OPERATION 

The entire Xrtd system is brought into operation 
when all four pieces of software are running. In 
practical application, the two pieces of software 
which transfer the raw tracking data run 
continuously. Only the latter two parts of the 
chain are generally started and stopped by the 
user. Additionally, the final part of the system, 
the Xrtd program itself, does not require real- 
time data, but can be run on old or simulated 
data. The rtd program is operated by giving it 
an input file which identifies the beginning time 
of data residuals to be calculated as well as the 
type (1 way Doppler, 2 way Doppler, 3 way 
Doppler, or range), and the desired tracking 


station to be monitored. This then outputs the 
standard ASCII file which can be read by Xrtd. 

3.1 Xrtd description 

As could be seen in Figure 2, Xrtd has many 
capabilities. A brief discussion of the major ones 
will be given here. 

3.1.1 File menu 

The file menu has two entries. Print Plot, and 
Exit. Print Plot generates a PostScript image of 
the file which is then dumped to a PostScript 
compatible laserprinter. Exit exits the Xrtd 
program. A dialog box allows the user to abort 
the exit if desired. 

3.1 .2 Options menu 

The Options menu is the primary menu of the 
Xrtd program. It allows you to perform most of 
the capabilities of the Xrtd program and has six 
entries. 

3.1. 2.1 Undisplay Plot 

This command causes the current plot to cease 
to exist. This command is not accessible from 
the first plot. 

3.1 .2.2 Change Scale 

This menu item allows the user to rescale the 
plot without using the mouse. This is to allow 
the user to scale the plot larger than that which 
is currently displayed. 

3.1.2.2.1 Max Scale 

This command changes the ordinate axis to 
include all data. 

3.1.2.2.2 MAD Scale 

This scaling changes the ordinate axis by using 
an algorithm designed to result in the best 
looking scale. This scale will not include 
isolated points which are grossly offscale. 

3.1.2.23 Show All Data 

This option changes both the ordinate and 
abscissa axes to include all data on scale. 
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3.1 .2.2.4 Manual Scale 

This allows the user to input exact scale values 
to be used. Both the ordinate and the abscissa 
may be input. 

3.1 .2.3 Create Child 

The Create Child sub-menu is the route by 
which the user spawns new plots and analyzes 
the data. 

3.1. 2.3.1 Add 

This simply adds a constant bias to all residuals 
3.1.2.32 Scale 

This input simply scales all residuals by an input 
scaling factor. 

3.1 .2.3.3 Average 

This allows the user to perform a forward 
looking moving average of the data. The 
number of points to average is a user input. 

3.1 .2.3.4 Difference Average 

This process calculates the difference between a 
given point and a centered average around the 
point. The number of points to use in the 
centered average is a user input. This process 
acts to filter out long period signatures in the 
data and to leave short period signatures 
present. 

3.1 .2.3.5 Integrate 

This process numerically integrates the 
residuals. This serves to convert Doppler 
residuals into the equivalent phase residual. 

This process often allows the user to see data 
characteristics that are too small to be discerned 
in the unintegrated data. 

3.1 .2.3.6 Model Bums 

This is a primary maneuver modeling tool. The 
user inputs the begin time, duration, initial 
value of residual at the beginning of the bum 
and final change in residual for any maneuvers. 
This capability allows the user to put in 


maneuvers that have not yet occurred and assess 
very accurately in real-time the relative 
performance of the actual maneuver. If the 
maneuver has already occurred, the user can 
input all of the values by outlining the 
maneuver with the mouse. This is demonstrated 
in Figure 3. 



Figure 3: Use of mouse to input bum information 

3.1 .2.3.7 Fit Bums 

This tool is similar to Model Bums, but rather 
than inputting the expected value for the 
maneuver. The software attempts to fit 
polynomials through the data. One polynomial 
is fit from the beginning of the data arc to the 
beginning of the user defined maneuver span, 
one is fit through the maneuver, and one is fit 
from the end of the maneuver to the end of the 
data arc or to the next maneuver. As with the 
Model Bums menu item, the initial time and 
duration can be input using the mouse rather 
than the keyboard. 

3.1.2.3.8 FFT 

This process will perform a Fast Fourier 
transform on the residuals. The beginning time 
for the transform and the number of points to be 
used are user inputs. The Fast Fourier 
Transform algorithm used requires the number 
of points used be a power of two. If not as many 
points exist after the beginning point as are 
requested, the plot will remain blank until 
enough points are available. 
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3.1.2.3.9 User Process 

This item allows the user to input the name of a 
user written, compiled, and linked program. 

The program allows the user to create any 
additional processes that are needed. The 
program reads in the timetag and residual from 
standard input and outputs the new timetag and 
residual to standard output. 

3.1 .2.4 Show Text Data 

The process shows a tabular listing of all the 
data displayed in the plot. The table is in three 
column format. The columns are point number, 
timetag (in Julian date), and residual. 

3.1 .2.5 Show Information 

This shows the results of the Fit Bums process. 
The output are polynomial coefficients and the 
time spans to which they apply. 

3.1 .2.6 Change Parameters 

This item allows the user to change the 
parameters of an already created window. 

4. CONCLUSION 

The Xrtd system has been utilized in its 
prototype form for two years. The system has 
performed wonderfully. Accurate 
determination of apparent maneuver 
performance has been achieved in only minutes 
compared to hours using previous systems. In 
addition, the Galileo Navigation Team has 
shown that the Fast Fourier Transform 
capability allows for rapid determination of spin 
rate and wobble amplitude. Xrtd has been used 
for the initial examination of the effectiveness of 
various attempts to free the Galileo High Gain 
Antenna. The system has regularly been used to 
determine the validity of data and to access in 
real-time the utility of various ground station 
configurations. 

The system however still has some drawbacks. 
The data flow interface was generated to fit 
networks existing at the time of its inception. 
Improved networking ability may provide the 
opportunity to improve overall performance by 
changing the data flow path. Finally, like all 
systems which rely only on Doppler and range 


data., all information obtained is only valid in 
the line of site between the receiving station and 
the spacecraft. To gain direct insight into the 
overall behavior, spacecraft telemetry data 
should be incorporated into the system. 
Currently, there is no capability for this. But it is 
hoped that future improvements to networking 
and data access will allow for the removal of 
these limitations. 

5. ACKNOWLEDGEMENTS 

The Xrtd system was originally developed as a 
Flight Project Support Office (FPSO) Advanced 
Technology Program proposal in 1990. Special 
acknowledgement must go to Earl Maize who 
led that original development as well as to those 
who contributed so much to the software used, 
Tim McElrath, Erik Slimko, and Peter Scott. 

The research described in this paper was carried 
out by the Jet Propulsion Laboratory, California 
Institute of Technology, under a contract with 
the National Aeronautics and Space 
Administration. 

Reference herein to any specific commercial 
product, process, or service by trade name, 
trademark, manufacturer, or otherwise, does not 
constitute or imply its endorsement by the 
United States government or the Jet Propulsion 
Laboratory, California Institute of Technology. 

6. REFERENCES 

1. Quercia, V., and O'Reilly, T., 1991, X Window 
System User's Guide, OSF/Motif Edition, 
Sebastapol, California: O'Reilly and Associates, 
Inc. 

2. Open Software Foundation, 1991, OSF/Motif 
Style Guide, Revision 1.1, Englewood Cliffs, New 
Jersey, Prentice Hall. 


606 



